This will consult with local shard only. If logicalcluster lives on different shard, this should fail.

Is this not the case? We should be using fallback informers?

I didn't test this with a shard setup but my intention here was to fetch a cluster using the path . By the way, the shard tests are passing, I guess everything's good.

im not sure sharding tests are testing this. And if both workspaces land on the same shard, it would pass. So failure would be transiant

I think this needs to be WithFallback to be able to resolve clusters frm other shards. If parent is located on other shard this will fail.

What does WithFallback mean in this case?
ps: I am actually trying to carryout a manual test with a shard setup, but havn't really had time to

Fallback takes 2 informers: the local shard and the cache server.
If the object is not found in the local shard informer, it goes to the cache server.
So cross-shard operation objects need to be replicated to the cache server so other shards can "consult" them.

@olamilekan000 ping

I didn't forget, but thanks for the Ping

Can you kindly review once more @mjudeikis

Typo: matchedSeclector → should be matchedSelector. This compiles fine since it's used consistently, but should be corrected for readability.

Silent edge case: Parent() error is silently discarded with _. For root workspaces (no LogicalClusterPathAnnotationKey annotation), parentPath will be zero-value and get passed to findSelectorInWorkspace, which will hit a not-found and fall back to matchAll: true. Harmless, but fragile. Suggest guarding:

if !parentPath.Empty() {
    if parentSelector := b.findSelectorInWorkspace(ctx, parentPath, exportRef, exportClaim); parentSelector != nil {
        selector = *parentSelector
    }
}

Parent doesn't retrun an error, it returns a path and a boolean